v6.18.x-openpax #5
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ping-Ke Shih says: ================== rtw patches for v6.18-rc7 Fix firmware goes wrong and causes device unusable after scanning. This issue presents under certain regulatory domain reported from end users. ================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
Replace close_cached_dir() calls under cfid_list_lock with a new close_cached_dir_locked() variant that uses kref_put() instead of kref_put_lock() to avoid recursive locking when dropping references. While the existing code works if the refcount >= 2 invariant holds, this area has proven error-prone. Make deadlocks impossible and WARN on invariant violations. Cc: [email protected] Reviewed-by: David Howells <[email protected]> Signed-off-by: Henrique Carvalho <[email protected]> Signed-off-by: Steve French <[email protected]>
Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=87be6809ed9bf6d718e3 Fixes: 24e0a1e ("cifs: switch to new mount api") Reviewed-by: David Howells <[email protected]> Signed-off-by: Shaurya Rane <[email protected]> Signed-off-by: Steve French <[email protected]>
Add the smb3_read_* tracepoints to SMB1's cifs_async_readv() and cifs_readv_callback(). Signed-off-by: David Howells <[email protected]> cc: Steve French <[email protected]> cc: Paulo Alcantara <[email protected]> cc: [email protected] cc: [email protected] Signed-off-by: Steve French <[email protected]>
Currently cpu-clock event always returns 0 count, e.g.,
perf stat -e cpu-clock -- sleep 1
Performance counter stats for 'sleep 1':
0 cpu-clock # 0.000 CPUs utilized
1.002308394 seconds time elapsed
The root cause is the commit 'bc4394e5e79c ("perf: Fix the throttle
error of some clock events")' adds PERF_EF_UPDATE flag check before
calling cpu_clock_event_update() to update the count, however the
PERF_EF_UPDATE flag is never set when the cpu-clock event is stopped in
counting mode (pmu->dev() -> cpu_clock_event_del() ->
cpu_clock_event_stop()). This leads to the cpu-clock event count is
never updated.
To fix this issue, force to set PERF_EF_UPDATE flag for cpu-clock event
just like what task-clock does.
Fixes: bc4394e ("perf: Fix the throttle error of some clock events")
Signed-off-by: Dapeng Mi <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Reviewed-by: Ian Rogers <[email protected]>
Acked-by: Namhyung Kim <[email protected]>
Link: https://patch.msgid.link/[email protected]
xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-torvalds#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-torvalds#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that. Cc: [email protected] # v6.10 Fixes: 2651923 ("xfs: online repair of symbolic links") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]>
Correct RGMII delay application logic in lan937x_set_tune_adj(). The function was missing `data16 &= ~PORT_TUNE_ADJ` before setting the new delay value. This caused the new value to be bitwise-OR'd with the existing PORT_TUNE_ADJ field instead of replacing it. For example, when setting the RGMII 2 TX delay on port 4, the intended TUNE_ADJUST value of 0 (RGMII_2_TX_DELAY_2NS) was incorrectly OR'd with the default 0x1B (from register value 0xDA3), leaving the delay at the wrong setting. This patch adds the missing mask to clear the field, ensuring the correct delay value is written. Physical measurements on the RGMII TX lines confirm the fix, showing the delay changing from ~1ns (before change) to ~2ns. While testing on i.MX 8MP showed this was within the platform's timing tolerance, it did not match the intended hardware-characterized value. Fixes: b19ac41 ("net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config") Cc: [email protected] Signed-off-by: Oleksij Rempel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
The L2TP stack did not reset the skb control buffer before sending the encapsulated package. In a setup with an ath10k radio and batman-adv over an L2TP tunnel massive fragmentations happen sporadically if the L2TP tunnel is established over IPv4. L2TP might reset some of the fields in the IP control buffer, but L2TP assumes the type of the control buffer to be of an IPv4 packet. In case the L2TP interface is used as a batadv hardif or the packet is an IPv6 packet, this assumption breaks. Clear the entire control buffer to avoid such mishaps altogether. Fixes: f77ae93 ("[PPPOL2TP]: Reset meta-data in xmit function") Signed-off-by: David Bauer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
…ux/kernel/git/wireless/wireless Johannes Berg says: ==================== wireless-2025-11-20 A single fix for scanning on some rtw89 devices. * tag 'wireless-2025-11-20' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: rtw89: hw_scan: Don't let the operating channel be last ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
Call scsi_device_put() in ata_scsi_dev_rescan() if the device or its queue are not running. Fixes: 0c76106 ("scsi: sd: Fix TCG OPAL unlock on system resume") Cc: [email protected] Signed-off-by: Yihang Li <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Niklas Cassel <[email protected]>
Commit cf3fc03 ("ata: libata-scsi: Fix ata_to_sense_error() status handling") fixed ata_to_sense_error() to properly generate sense key ABORTED COMMAND (without any additional sense code), instead of the previous bogus sense key ILLEGAL REQUEST with the additional sense code UNALIGNED WRITE COMMAND, for a failed command. However, this broke suspend for Security locked drives (drives that have Security enabled, and have not been Security unlocked by boot firmware). The reason for this is that the SCSI disk driver, for the Synchronize Cache command only, treats any sense data with sense key ILLEGAL REQUEST as a successful command (regardless of ASC / ASCQ). After commit cf3fc03 ("ata: libata-scsi: Fix ata_to_sense_error() status handling") the code that treats any sense data with sense key ILLEGAL REQUEST as a successful command is no longer applicable, so the command fails, which causes the system suspend to be aborted: sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5 sd 1:0:0:0: PM: failed to suspend async: error -5 PM: Some devices failed to suspend, or early wake event detected To make suspend work once again, for a Security locked device only, return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense data which a real SCSI device would have returned if locked. The SCSI disk driver treats this sense data as a successful command. Cc: [email protected] Reported-by: Ilia Baryshnikov <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704 Fixes: cf3fc03 ("ata: libata-scsi: Fix ata_to_sense_error() status handling") Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Niklas Cassel <[email protected]>
For Security locked drives (drives that have Security enabled, and have
not been Security unlocked by boot firmware), the automatic partition
scanning will result in the user being spammed with errors such as:
ata5.00: failed command: READ DMA
ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 7 dma 4096 in
res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
ata5.00: status: { DRDY ERR }
ata5.00: error: { ABRT }
sd 4:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
sd 4:0:0:0: [sda] tag#7 Sense Key : Aborted Command [current]
sd 4:0:0:0: [sda] tag#7 Add. Sense: No additional sense information
during boot, because most commands except for IDENTIFY will be aborted by
a Security locked drive.
For a Security locked drive, set capacity to zero, so that no automatic
partition scanning will happen.
If the user later unlocks the drive using e.g. hdparm, the close() by the
user space application should trigger a revalidation of the drive.
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Signed-off-by: Niklas Cassel <[email protected]>
… block-6.18 Pull NVMe fixes from Keith: "nvme fixes for Linux 6.18 - Admin queue use-after-free fix (Keith) - Target authentication fix (Alistar) - Multipath lockdeup fix (Shin'ichiro) - FC transport teardown fixes (Ewan)" * tag 'nvme-6.18-2025-11-20' of git://git.infradead.org/nvme: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl() nvme-multipath: fix lockdep WARN due to partition scan work nvmet-auth: update sc_c in target host hash calculation nvme: fix admin request_queue lifetime
be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c340 ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states. The correct way would be to pass the wrb_params from be_xmit(). Fixes: 760c295 ("be2net: Support for OS2BMC.") Cc: [email protected] Signed-off-by: Andrey Vatoropin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/[email protected]/ [2]: https://lore.kernel.org/netdev/[email protected]/ [3]: https://lore.kernel.org/netdev/[email protected]/ Fixes: d021c34 ("VSOCK: Introduce VM Sockets") Signed-off-by: Michal Luczaj <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
tk_aux_sysfs_init() returns immediately on error during the auxiliary clock initialization loop without cleaning up previously allocated kobjects and sysfs groups. If kobject_create_and_add() or sysfs_create_group() fails during loop iteration, the parent kobjects (tko and auxo) and any previously created child kobjects are leaked. Fix this by adding proper error handling with goto labels to ensure all allocated resources are cleaned up on failure. kobject_put() on the parent kobjects will handle cleanup of their children. Fixes: 7b95663 ("timekeeping: Provide interface to control auxiliary clocks") Signed-off-by: Malaya Kumar Rout <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://patch.msgid.link/[email protected]
…/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from IPsec and wireless.
Previous releases - regressions:
- prevent NULL deref in generic_hwtstamp_ioctl_lower(),
newer APIs don't populate all the pointers in the request
- phylink: add missing supported link modes for the fixed-link
- mptcp: fix false positive warning in mptcp_pm_nl_rm_addr
Previous releases - always broken:
- openvswitch: remove never-working support for setting NSH fields
- xfrm: number of fixes for error paths of xfrm_state creation/
modification/deletion
- xfrm: fixes for offload
- fix the determination of the protocol of the inner packet
- don't push locally generated packets directly to L2 tunnel
mode offloading, they still need processing from the standard
xfrm path
- mptcp: fix a couple of corner cases in fallback and fastclose
handling
- wifi: rtw89: hw_scan: prevent connections from getting stuck,
work around apparent bug in FW by tweaking messages we send
- af_unix: fix duplicate data if PEEK w/ peek_offset needs to wait
- veth: more robust handing of race to avoid txq getting stuck
- eth: ps3_gelic_net: handle skb allocation failures"
* tag 'net-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (47 commits)
vsock: Ignore signal/timeout on connect() if already established
be2net: pass wrb_params in case of OS2BMC
l2tp: reset skb control buffer on xmit
net: dsa: microchip: lan937x: Fix RGMII delay tuning
selftests: mptcp: add a check for 'add_addr_accepted'
mptcp: fix address removal logic in mptcp_pm_nl_rm_addr
selftests: mptcp: join: userspace: longer timeout
selftests: mptcp: join: endpoints: longer timeout
selftests: mptcp: join: fastclose: remove flaky marks
mptcp: fix duplicate reset on fastclose
mptcp: decouple mptcp fastclose from tcp close
mptcp: do not fallback when OoO is present
mptcp: fix premature close in case of fallback
mptcp: avoid unneeded subflow-level drops
mptcp: fix ack generation for fallback msk
wifi: rtw89: hw_scan: Don't let the operating channel be last
net: phylink: add missing supported link modes for the fixed-link
selftest: af_unix: Add test for SO_PEEK_OFF.
af_unix: Read sk_peek_offset() again after sleeping in unix_stream_read_generic().
net/mlx5: Clean up only new IRQ glue on request_irq() failure
...
…scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Ilpo Järvinen:
"This one has lots of new HW entries which adds to the size in diffstat
but the individual changes are simple.
Fixes
- acer-wmi: Ignore backlight event
- alienware-wmi-wmax: Fix quirk match table order & drop redundant
entries
- amd/pmc:
- Add Xbox Ally to spurious 8042 quirk list
- Quirk list Lenovo Legion Go 2 NVMe resume
- msi-wmi-platform:
- Correct GUID to uppercase
- GUID is uncleverly copy-pasted from an example so add a DMI
whitelist
- intel/speed_select_if: PCIBIOS_* return code conversion
- intel-uncore-freq & ISST: Fix kernel doc warnings
New HW support
- alienware-wmi-wmax:
- Alienware 16 Aurora support
- Alienware M support
- Alienware X support
- Dell G support
- amd/pmc:
- ROG Xbox Ally (non-X) support
- huaway-wmi: HONOR MagicBoox X16/X14 PrintScreen & YOYO keys
- hp-wmi:
- Omen 16-wf1xxx fan support
- Omen MAX 16-ah0xx fan + thermal profile support
- Victus 16-r0 and 16-s0 fan + thermal profile support
- intel/hid: Intel Nova Lake support
- intel-uncore-freq:
- Intel Panther Lake support
- Intel Wildcat Lake support
- Intel Nova Lake support"
* tag 'platform-drivers-x86-v6.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (21 commits)
platform/x86: intel-uncore-freq: fix all header kernel-doc warnings
platform/x86: acer-wmi: Ignore backlight event
platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to errnos
platform/x86/intel/hid: Add Nova Lake support
platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16 Aurora
platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal profile
platform/x86: msi-wmi-platform: Fix typo in WMI GUID
platform/x86: msi-wmi-platform: Only load on MSI devices
platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list
platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally
platform/x86/amd/pmc: Add support for Van Gogh SoC
platform/x86: alienware-wmi-wmax: Add support for the whole "G" family
platform/x86: alienware-wmi-wmax: Add support for the whole "X" family
platform/x86: alienware-wmi-wmax: Add support for the whole "M" family
platform/x86: alienware-wmi-wmax: Drop redundant DMI entries
platform/x86: alienware-wmi-wmax: Fix "Alienware m16 R1 AMD" quirk order
platform/x86: ISST: isst_if.h: fix all kernel-doc warnings
platform/x86: intel-uncore-freq: Add additional client processors
platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support
platform/x86: huawei-wmi: add keys for HONOR models
...
…l/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "This fixes EINJV2 support introduced during the 6.17 cycle by unbreaking the initialization broken by a previous attempted fix, adding sanity checks for data coming from the platform firmware, and updating the code to handle injecting legacy error types on an EINJV2 capable systems properly (Tony Luck)" * tag 'acpi-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: APEI: EINJ: Fix EINJV2 initialization and injection
…git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix a regression introduced during the 6.16 development cycle that may cause runtime PM to be enabled by mistake for devices that do not support it (which may lead to some serious trouble) if there is a system wakeup event during the "late suspend" phase of system suspend" * tag 'pm-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: sleep: core: Fix runtime PM enabling in device_resume_early()
If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up. Cc: [email protected] Reported-by: Google Big Sleep <[email protected]> Fixes: 9e4ed35 ("io_uring/netcmd: add tx timestamping cmd support") Signed-off-by: Jens Axboe <[email protected]>
A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure. Fixes: bff3b5a ("sched_ext: Move disable machinery into scx_sched") Cc: [email protected] # v6.16+ Reported-and-tested-by: Samir Mulani <[email protected]> Signed-off-by: Saket Kumar Bhaskar <[email protected]> Reviewed-by: Emil Tsalapatis <[email protected]> Reviewed-by: Andrea Righi <[email protected]> Reviewed-by: Vishal Chourasia <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
…ernel/git/vbabka/slab Pull slab fix from Vlastimil Babka: - Fix mempool poisoning order>0 pages with CONFIG_HIGHMEM (Vlastimil Babka) * tag 'slab-for-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: mm/mempool: fix poisoning order>0 pages with HIGHMEM
… end An empty flush bio can have arbitrary bi_sector. The commit 2b1c6d7 introduced a regression that device mapper would fail an empty flush bio with -EIO if the sector pointed beyond the end of the device. The commit introduced an optimization, that optimization would pass flushes to __split_and_process_bio and __split_and_process_bio is not prepared to handle empty bios. Fix this bug by passing only non-empty flushes to __split_and_process_bio - non-empty flushes must have valid bi_sector. Empty bios will go through __send_empty_flush, as they did before the optimization. This problem can be reproduced by running the lvm2 test: make check_local T=lvconvert-thin.sh LVM_TEST_PREFER_BRD=0 Signed-off-by: Mikulas Patocka <[email protected]> Fixes: 2b1c6d7 ("dm: optimize REQ_PREFLUSH with data when using the linear target") Reported-by: Zdenek Kabelac <[email protected]> Reviewed-by: Bart Van Assche <[email protected]>
…b/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fix from Tejun Heo: "One low risk and obvious fix: scx_enable() was dereferencing an error pointer on helper kthread creation failure. Fixed" * tag 'sched_ext-for-6.18-rc6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Fix scx_enable() crash on helper kthread creation failure
Before Linux had cred structures, the SELinux task_security_struct was per-task and although the structure was switched to being per-cred long ago, the name was never updated. This change renames it to cred_security_struct to avoid confusion and pave the way for the introduction of an actual per-task security structure for SELinux. No functional change. Cc: [email protected] Signed-off-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]>
The avdcache is meant to be per-task; move it to a new task_security_struct that is duplicated per-task. Cc: [email protected] Fixes: 5d7ddc5 ("selinux: reduce path walk overhead") Signed-off-by: Stephen Smalley <[email protected]> [PM: line length fixes] Signed-off-by: Paul Moore <[email protected]>
Along with the renaming from task_security_struct to cred_security_struct, rename the local variables to "crsec" from "tsec". This both fits with existing conventions and helps distinguish between task and cred related variables. No functional changes. Acked-by: Stephen Smalley <[email protected]> Signed-off-by: Paul Moore <[email protected]>
…nterface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------ Fixes: ceac1cb ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Chris Lu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
HCI_OP_NOP means no command was actually sent so there is no point in triggering cmd_timer which may cause a hdev->reset in the process since it is assumed that the controller is stuck processing a command. Fixes: e2d471b ("Bluetooth: ISO: Fix not using SID from adv report") Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
This configuration knob enables OpenPaX soft mode, wherein OpenPaX features will be disabled by default, with OpenPaX features only enforcing on binaries where OpenPaX has been explicitly configured. Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
… might be a trampoline Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Stack trampoline definitions were derived from the original PaX. Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
… enabled Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Stack mapping entropy is currently hard-wired to 11 bits of entropy on 32-bit and 18 bits of entropy on 64-bit. The stack itself gains an extra 8 bits of entropy from lower bit randomization within 16 byte alignment constraints. The argument block could have all lower bits randomized but it currently only gets the mapping randomization. Rather than hard-wiring values this switches to using the mmap entropy configuration like the mmap base and executable base, resulting in a range of 8 to 16 bits on 32-bit and 18 to 24 bits on 64-bit (with 4k pages and 3 level page tables) depending on kernel configuration and overridable via the sysctl entries. It's worth noting that since these kernel configuration options default to the minimum supported entropy value, the entropy on 32-bit will drop from 11 to 8 bits for builds using the defaults. However, following the configuration seems like the right thing to do regardless. At the very least, changing the defaults for COMPAT (32-bit processes on 64-bit) should be considered due to the larger address space compared to real 32-bit. Signed-off-by: Daniel Micay <[email protected]> Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Stack mapping entropy is currently hard-wired to 11 bits of entropy on 32-bit and 22 bits of entropy on 64-bit. The stack itself gains an extra 8 bits of entropy from lower bit randomization within 16 byte alignment constraints. The argument block could have all lower bits randomized but it currently only gets the mapping randomization. Rather than hard-wiring values this switches to using the mmap entropy configuration like the mmap base and executable base, resulting in a range of 8 to 16 bits on 32-bit and 28 to 32 bits on 64-bit depending on kernel configuration and overridable via the sysctl entries. It's worth noting that since these kernel configuration options default to the minimum supported entropy value, the entropy on 32-bit will drop from 11 to 8 bits for builds using the defaults. However, following the configuration seems like the right thing to do regardless. At the very least, changing the defaults for COMPAT (32-bit processes on 64-bit) should be considered due to the larger address space compared to real 32-bit. Signed-off-by: Daniel Micay <[email protected]> Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
This code mostly inspired by linux-hardened patch set. Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Signed-off-by: Daniel Micay <[email protected]> Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Previously we would read randomize_va_space in openpax_setup_flags, and then again later after calling openpax_setup_flags. As randomize_va_space is a sysctl, its value can change at any time. Accordingly, snapshot randomize_va_space before calling openpax_set_flags and pass the snapshot value to openpax_set_flags. This resolves a minor race condition where one may be able to slightly weaken process ASLR by turning ASLR on or off during an exec call. Signed-off-by: Ariadne Conill <[email protected]> Signed-off-by: Quinn Diggity <[email protected]>
Otherwise we have to add a bunch of #ifdefs when we otherwise
would not need to.
Fixes: a78588f6fc2f2 ("init: add pax_softmode= kernel command-line option")
Fixes: edera-dev#1
Signed-off-by: Ariadne Conill <[email protected]>
Signed-off-by: Quinn Diggity <[email protected]>
quinndiggity
force-pushed
the
quinn/v6.18.x-openpax
branch
from
a58ea04 to
dd44ac7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Just a rebasing onto
linux-6.18.y- only basic testing has been performed.For testing, I've built this against a
genericubuntu-based kernel config forv6.18, generated via:and with that generated
.config, updated it forv6.18, with the newest settings' defaults filled in via:built with:
For the test system, used
pax_softmode=1along withsecurity=tomoyo, to usetomoyo-editpolicy /etc/tomoyoin system-wide learning mode (in order to easilypaxmarkall thegjsrelated things), before settingpax_softmode=0and rebooting to confirm thatgdmand the entiregnomeshell environment was working correctly.Have done basic testing, confirming that these features, so far, seemingly function as expected:
OPENPAX_SOFTMODEOPENPAX_XATTR_PAX_FLAGSOPENPAX_MPROTECTFor a cleaner view of just these commits, against mainline
linux-6.18.y, check out: https://github.com/quinndiggity/linux-openpax/pull/1/commits