fs/proc: fix softlockup in readvmcore (part 2)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it
Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wakedepth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged:
kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irqsetirqwake+0x147/0x1a0
The PMC driver uses DEFINESIMPLEDEVPMOPS() to define its devpmops which sets amdpmcsuspendhandler() to the .suspend, .freeze, and .poweroff handlers. i8042pmsuspend(), however, is only set as the .suspend handler.
Fix the issue by call PMC suspend handler only from the same set of devpmops handlers as i8042pmsuspend(), which currently means just the .suspend handler.
To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first.
[ij: edited the commit message.]
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: clamp maximum hashtable size to INTMAX
Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset. See:
0708a0afe291 ("mm: Consider GFPNOWARN flag for oversized kvmalloc() calls")
Note: hashtable resize is only possible from initnetns.
exfat: fix the infinite loop in exfatreaddir()
In the Linux kernel, the following vulnerability has been resolved:
mac802154: check local interfaces before deleting sdata list
syzkaller reported a corrupted list in ieee802154ifremove. [1]
Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 hardware device from the system.
CPU0 CPU1 ==== ==== genlfamilyrcvmsgdoit ieee802154unregisterhw ieee802154deliface ieee802154removeinterfaces rdevdelvirtualintfdeprecated listdel(&sdata->list) ieee802154ifremove listdelrcu
The net device has been unregistered, since the rcu grace period, unregistration must be run before ieee802154ifremove.
To avoid this issue, add a check for local->interfaces before deleting sdata list.
[1] kernel BUG at lib/listdebug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:listdelentryvalidorreport+0xf4/0x140 lib/listdebug.c:56 Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7 RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246 RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000 R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> listdelentryvalid include/linux/list.h:124 [inline] listdelentry include/linux/list.h:215 [inline] listdelrcu include/linux/rculist.h:157 [inline] ieee802154ifremove+0x86/0x1e0 net/mac802154/iface.c:687 rdevdelvirtualintfdeprecated net/ieee802154/rdev-ops.h:24 [inline] ieee802154deliface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] socksendmsg+0x221/0x270 net/socket.c:744 syssendmsg+0x52a/0x7e0 net/socket.c:2607 syssendmsg net/socket.c:2661 [inline] syssendmsg+0x292/0x380 net/socket.c:2690 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
fs: relax assertions on failure to encode file handles
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ffs: Remove WARNON in functionfsbind
This commit addresses an issue related to below kernel panic where paniconwarn is enabled. It is caused by the unnecessary use of WARNON in functionsfsbind, which easily leads to the following scenarios.
1.adbwrite in adbd 2. UDC write via configfs ================= =====================
->usbffsopenthread() ->UDC write ->openfunctionfs() ->configfswriteiter() ->adbopen() ->gadgetdevdescUDCstore() ->adbwrite() ->usbgadgetregisterdriverowner ->driverregister() ->StartMonitor() ->busadddriver() ->adbread() ->gadgetbinddriver() <times-out without BIND event> ->configfscompositebind() ->usbaddfunction() ->openfunctionfs() ->ffsfuncbind() ->adbopen() ->functionfsbind() <ffs->state !=FFSACTIVE>
The adbopen, adbread, and adbwrite operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARNON from functionfsbind when paniconwarn is enabled. This commit fixes the kernel panic by removing the unnecessary WARNON.
Kernel panic - not syncing: kernel: paniconwarn set ... [ 14.542395] Call trace: [ 14.542464] ffsfuncbind+0x1c8/0x14a8 [ 14.542468] usbaddfunction+0xcc/0x1f0 [ 14.542473] configfscompositebind+0x468/0x588 [ 14.542478] gadgetbinddriver+0x108/0x27c [ 14.542483] reallyprobe+0x190/0x374 [ 14.542488] driverprobedevice+0xa0/0x12c [ 14.542492] driverprobedevice+0x3c/0x220 [ 14.542498] driverattach+0x11c/0x1fc [ 14.542502] busforeachdev+0x104/0x160 [ 14.542506] driverattach+0x24/0x34 [ 14.542510] busadddriver+0x154/0x270 [ 14.542514] driverregister+0x68/0x104 [ 14.542518] usbgadgetregisterdriverowner+0x48/0xf4 [ 14.542523] gadgetdevdescUDCstore+0xf8/0x144 [ 14.542526] configfswriteiter+0xf0/0x138
In the Linux kernel, the following vulnerability has been resolved:
quota: flush quotareleasework upon quota writeback
One of the paths quota writeback is called from is:
freezesuper() syncfilesystem() ext4syncfs() dquotwritebackdquots()
Since we currently don't always flush the quotareleasework queue in this path, we can end up with the following race:
1. dquot are added to releasingdquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quotareleasework queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARNON since transaction gets started during frozen state:
ext4journalcheckstart+0x28/0x110 [ext4] (unreliable) ext4journalstartsb+0x64/0x1c0 [ext4] ext4releasedquot+0x90/0x1d0 [ext4] quotareleaseworkfn+0x43c/0x4d0
Which is the following line:
WARNON(sb->swriters.frozen == SBFREEZECOMPLETE);
Which ultimately results in generic/390 failing due to dmesg noise. This was detected on powerpc machine 15 cores.
To avoid this, make sure to flush the workqueue during dquotwritebackdquots() so we dont have any pending workitems after freeze.
In the Linux kernel, the following vulnerability has been resolved:
mm: vmscan: account for free pages to prevent infinite Loop in throttledirectreclaim()
The task sometimes continues looping in throttledirectreclaim() because allowdirectreclaim(pgdat) keeps returning false.
#0 [ffff80002cb6f8d0] switchto at ffff8000080095ac #1 [ffff80002cb6f900] schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttledirectreclaim at ffff800008273550 #4 [ffff80002cb6fa20] trytofreepages at ffff800008277b68 #5 [ffff80002cb6fae0] allocpagesnodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] allocpagesvma at ffff8000082e4a98 #7 [ffff80002cb6fca0] doanonymouspage at ffff80000829f5a8 #8 [ffff80002cb6fce0] handlemmfault at ffff8000082a5974 #9 [ffff80002cb6fd90] handlemmfault at ffff8000082a5bd4
At this point, the pgdat contains the following two zones:
NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VMSTAT: NRFREEPAGES: 359 NRZONEINACTIVEANON: 18813 NRZONEACTIVEANON: 0 NRZONEINACTIVEFILE: 50 NRZONEACTIVEFILE: 0 NRZONEUNEVICTABLE: 0 NRZONEWRITEPENDING: 0 NRMLOCK: 0 NRBOUNCE: 0 NRZSPAGES: 0 NRFREECMAPAGES: 0
NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VMSTAT: NRFREEPAGES: 146 NRZONEINACTIVEANON: 94668 NRZONEACTIVEANON: 3 NRZONEINACTIVEFILE: 735 NRZONEACTIVEFILE: 78 NRZONEUNEVICTABLE: 0 NRZONEWRITEPENDING: 0 NRMLOCK: 0 NRBOUNCE: 0 NRZSPAGES: 0 NRFREECMAPAGES: 0
In allowdirectreclaim(), while processing ZONEDMA32, the sum of inactive/active file-backed pages calculated in zonereclaimablepages() based on the result of zonepagestatesnapshot() is zero.
Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped.
crash> p nrswappages nrswappages = $1937 = { counter = 0 }
As a result, ZONEDMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONENORMAL, despite ZONEDMA32 having free pages significantly exceeding the high watermark.
The problem is that the pgdat->kswapdfailures hasn't been incremented.
crash> px ((struct pglistdata ) 0xffff00817fffe540)->kswapdfailures $1935 = 0x0
This is because the node deemed balanced. The node balancing logic in balancepgdat() evaluates all zones collectively. If one or more zones (e.g., ZONEDMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balancepgdat() to exit early before incrementing the kswapdfailures, as it considers the overall memory state acceptable, even though some zones (like ZONENORMAL) remain under significant pressure.
The patch ensures that zonereclaimablepages() includes free pages (NRFREEPAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONEDMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONENORMAL, and prevents infinite loops in throttledirectreclaim() caused by allowdirectreclaim(pgdat) repeatedly returning false.
The kernel hangs due to a task stuck in throttledirectreclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONENORMAL. This issue arises from zonereclaimablepages ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net/sched: netem: account for backlog updates from child qdisc
In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisctreereducebacklog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full.
Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms
Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif>
Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0
Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0
tbf segments the GSO SKBs (tbfsegment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted.
This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics.
ALSA: control: Avoid WARN() for symlink errors
In the Linux kernel, the following vulnerability has been resolved:
net: Fix icmp host relookup triggering iprtbug
arp link failure may trigger iprtbug while xfrm enabled, call trace is:
WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 iprtbug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iprtbug+0x14/0x20 Call Trace: <IRQ> ipsendskb+0x14/0x40 icmpsend+0x42d/0x6a0 ipv4linkfailure+0xe2/0x1d0 arperrorreport+0x3c/0x50 neighinvalidate+0x8d/0x100 neightimerhandler+0x2e1/0x330 calltimerfn+0x21/0x120 runtimerbase.part.0+0x1c9/0x270 runtimersoftirq+0x4c/0x80 handlesoftirqs+0xac/0x280 irqexitrcu+0x62/0x80 sysvecapictimerinterrupt+0x77/0x90
The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1
icmproutelookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = iprtbug) to skb for DESTUNREACH.
For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disablexfrm = 1).
Skip icmp relookup for locally generated packets to fix it.
In the Linux kernel, the following vulnerability has been resolved:
bcache: revert replacing ISERRORNULL with ISERR again
Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cachesetflush().
1721 if (!ISERRORNULL(c->root)) 1722 listadd(&c->root->list, &c->btreecache);
From the above code in cachesetflush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. bchbtreenodealloc() never returns NULL but c->root is possible to be NULL at above line 1721.
This patch replaces ISERR() by ISERRORNULL() to fix this.
bpf: Fix bpfskselectreuseport() memory leak
In the Linux kernel, the following vulnerability has been resolved:
vsock: prevent null-ptr-deref in vsock[hasdata|hasspace]
Recent reports have shown how we sometimes call vsockhasdata() when a vsock socket has been de-assigned from a transport (see attached links), but we shouldn't.
Previous commits should have solved the real problems, but we may have more in the future, so to avoid null-ptr-deref, we can return 0 (no space, no data available) but with a warning.
This way the code should continue to run in a nearly consistent state and have a warning that allows us to debug future problems.
In the Linux kernel, the following vulnerability has been resolved:
netsched: clsflow: validate TCAFLOWRSHIFT attribute
syzbot found that TCAFLOWRSHIFT attribute was not validated. Right shitfing a 32bit integer is undefined for large shift values.
UBSAN: shift-out-of-bounds in net/sched/clsflow.c:329:23 shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: ipv6addrconf addrconfdadwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:231 [inline] ubsanhandleshiftoutofbounds+0x3c8/0x420 lib/ubsan.c:468 flowclassify+0x24d5/0x25b0 net/sched/clsflow.c:329 tcclassify include/net/tcwrapper.h:197 [inline] tcfclassify net/sched/clsapi.c:1771 [inline] tcfclassify+0x420/0x1160 net/sched/clsapi.c:1867 sfbclassify net/sched/schsfb.c:260 [inline] sfbenqueue+0x3ad/0x18b0 net/sched/schsfb.c:318 devqdiscenqueue+0x4b/0x290 net/core/dev.c:3793 devxmitskb net/core/dev.c:3889 [inline] devqueuexmit+0xf0e/0x3f50 net/core/dev.c:4400 devqueuexmit include/linux/netdevice.h:3168 [inline] neighhhoutput include/net/neighbour.h:523 [inline] neighoutput include/net/neighbour.h:537 [inline] ipfinishoutput2+0xd41/0x1390 net/ipv4/ipoutput.c:236 iptunnelxmit+0x55d/0x9b0 net/ipv4/iptunnelcore.c:82 udptunnelxmitskb+0x262/0x3b0 net/ipv4/udptunnelcore.c:173 genevexmitskb drivers/net/geneve.c:916 [inline] genevexmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 netdevstartxmit include/linux/netdevice.h:5002 [inline] netdevstartxmit include/linux/netdevice.h:5011 [inline] xmitone net/core/dev.c:3590 [inline] devhardstartxmit+0x27a/0x7d0 net/core/dev.c:3606 devqueuexmit+0x1b73/0x3f50 net/core/dev.c:4434
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: rtomin/max: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using containerof().
Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use 'data' everywhere 'net->sctp.rtomin/max' is used.
In the Linux kernel, the following vulnerability has been resolved:
workqueue: Do not warn when cancelling WQMEMRECLAIM work from !WQMEMRECLAIM worker
After commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQMEMRECLAIM") amdgpu started seeing the following warning:
[ ] workqueue: WQMEMRECLAIM sdma0:drmschedrunjobwork [gpusched] is flushing !WQMEMRECLAIM events:amdgpudevicedelayenablegfxoff [amdgpu] ... [ ] Workqueue: sdma0 drmschedrunjobwork [gpusched] ... [ ] Call Trace: [ ] <TASK> ... [ ] ? checkflushdependency+0xf5/0x110 ... [ ] canceldelayedworksync+0x6e/0x80 [ ] amdgpugfxoffctrl+0xab/0x140 [amdgpu] [ ] amdgpuringalloc+0x40/0x50 [amdgpu] [ ] amdgpuibschedule+0xf4/0x810 [amdgpu] [ ] ? drmschedrunjobwork+0x22c/0x430 [gpusched] [ ] amdgpujobrun+0xaa/0x1f0 [amdgpu] [ ] drmschedrunjobwork+0x257/0x430 [gpusched] [ ] processonework+0x217/0x720 ... [ ] </TASK>
The intent of the verifcation done in checkflushdepedency is to ensure forward progress during memory reclaim, by flagging cases when either a memory reclaim process, or a memory reclaim work item is flushed from a context not marked as memory reclaim safe.
This is correct when flushing, but when called from the cancel(delayed)worksync() paths it is a false positive because work is either already running, or will not be running at all. Therefore cancelling it is safe and we can relax the warning criteria by letting the helper know of the calling context.
References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQMEMRECLAIM")
In the Linux kernel, the following vulnerability has been resolved:
mm: clear uffd-wp PTE/PMD state on mremap()
When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.
Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: clear link ID from bitmap during link delete after clean up
Currently, during link deletion, the link ID is first removed from the validlinks bitmap before performing any clean-up operations. However, some functions require the link ID to remain in the validlinks bitmap. One such example is cfg80211cacevent(). The flow is -
nl80211removelink() cfg80211removelink() ieee80211delintflink() ieee80211vifsetlinks() ieee80211vifupdatelinks() ieee80211linkstop() cfg80211cacevent()
cfg80211cacevent() requires link ID to be present but it is cleared already in cfg80211removelink(). Ultimately, WARNON() is hit.
Therefore, clear the link ID from the bitmap only after completing the link clean-up.
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: must allocate more bytes for RedBox support
Blamed commit forgot to change hsrinitskb() to allocate larger skb for RedBox case.
Indeed, sendhsrsupervisionframe() will add two additional components (struct hsrsuptlv and struct hsrsuppayload)
syzbot reported the following crash: skbuff: skboverpanic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 UID: 0 PID: 7611 Comm: syz-executor Not tainted 6.12.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:skbpanic+0x157/0x1d0 net/core/skbuff.c:206 Code: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282 RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69 RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005 RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a R13: 0000000000000006 R14: ffff88804b938130 R15: 0000000000000140 FS: 000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> skboverpanic net/core/skbuff.c:211 [inline] skbput+0x174/0x1b0 net/core/skbuff.c:2617 sendhsrsupervisionframe+0x6fa/0x9e0 net/hsr/hsrdevice.c:342 hsrproxyannounce+0x1a3/0x4a0 net/hsr/hsrdevice.c:436 calltimerfn+0x1a0/0x610 kernel/time/timer.c:1794 expiretimers kernel/time/timer.c:1845 [inline] runtimers+0x6e8/0x930 kernel/time/timer.c:2419 runtimerbase kernel/time/timer.c:2430 [inline] runtimerbase kernel/time/timer.c:2423 [inline] runtimerbase+0x111/0x190 kernel/time/timer.c:2439 runtimersoftirq+0x1a/0x40 kernel/time/timer.c:2449 handlesoftirqs+0x213/0x8f0 kernel/softirq.c:554 dosoftirq kernel/softirq.c:588 [inline] invokesoftirq kernel/softirq.c:428 [inline] irqexitrcu kernel/softirq.c:637 [inline] irqexitrcu+0xbb/0x120 kernel/softirq.c:649 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: don't auto enable misc vector
Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below:
[ 16.324639] Call trace: [ 16.324641] queuedelayedwork+0xb8/0xe0 [ 16.324643] moddelayedworkon+0x78/0xd0 [ 16.324655] hclgeerrhandtaskschedule+0x58/0x90 [hclge] [ 16.324662] hclgemiscirqhandle+0x168/0x240 [hclge] [ 16.324666] handleirqeventpercpu+0x64/0x1e0 [ 16.324667] handleirqevent+0x80/0x170 [ 16.324670] handlefasteoiedgeirq+0x110/0x2bc [ 16.324671] handledomainirq+0x84/0xfc [ 16.324673] gichandleirq+0x88/0x2c0 [ 16.324674] el1irq+0xb8/0x140 [ 16.324677] archcpuidle+0x18/0x40 [ 16.324679] defaultidlecall+0x5c/0x1bc [ 16.324682] cpuidleidlecall+0x18c/0x1c4 [ 16.324684] doidle+0x174/0x17c [ 16.324685] cpustartupentry+0x30/0x6c [ 16.324687] secondarystartkernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]---
So don't auto enable misc vector when request irq..
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when 1588 is sent on HIP08 devices
Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTXHWTSTAMP flag and cause a kernel crash.
[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclgeptpsettxinfo+0x2c/0x140 [hclge] [ 128.286600] lr : hclgeptpsettxinfo+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclgeptpsettxinfo+0x2c/0x140 [hclge] [ 128.399893] hns3nicnetxmit+0x39c/0x4c4 [hns3] [ 128.405468] xmitone.constprop.0+0xc4/0x200 [ 128.410600] devhardstartxmit+0x54/0xf0 [ 128.415556] schdirectxmit+0xe8/0x634 [ 128.420246] devqueuexmit+0x224/0xc70 [ 128.425101] devqueuexmit+0x1c/0x40 [ 128.429608] ovsvportsend+0xac/0x1a0 [openvswitch] [ 128.435409] dooutput+0x60/0x17c [openvswitch] [ 128.440770] doexecuteactions+0x898/0x8c4 [openvswitch] [ 128.446993] ovsexecuteactions+0x64/0xf0 [openvswitch] [ 128.453129] ovsdpprocesspacket+0xa0/0x224 [openvswitch] [ 128.459530] ovsvportreceive+0x7c/0xfc [openvswitch] [ 128.465497] internaldevxmit+0x34/0xb0 [openvswitch] [ 128.471460] xmitone.constprop.0+0xc4/0x200 [ 128.476561] devhardstartxmit+0x54/0xf0 [ 128.481489] devqueuexmit+0x968/0xc70 [ 128.486330] devqueuexmit+0x1c/0x40 [ 128.490856] ipfinishoutput2+0x250/0x570 [ 128.495810] ipfinishoutput+0x170/0x1e0 [ 128.500832] ipfinishoutput+0x3c/0xf0 [ 128.505504] ipoutput+0xbc/0x160 [ 128.509654] ipsendskb+0x58/0xd4 [ 128.513892] udpsendskb+0x12c/0x354 [ 128.518387] udpsendmsg+0x7a8/0x9c0 [ 128.522793] inetsendmsg+0x4c/0x8c [ 128.527116] socksendmsg+0x48/0x80 [ 128.531609] syssendto+0x124/0x164 [ 128.536099] arm64syssendto+0x30/0x5c [ 128.540935] invokesyscall+0x50/0x130 [ 128.545508] el0svccommon.constprop.0+0x10c/0x124 [ 128.551205] doel0svc+0x34/0xdc [ 128.555347] el0svc+0x20/0x30 [ 128.559227] el0synchandler+0xb8/0xc0 [ 128.563883] el0sync+0x160/0x180
In the Linux kernel, the following vulnerability has been resolved:
riscv: Fix sleeping in invalid context in die()
die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlockt which can sleep with PREEMPTRT enabled. That causes the following warning:
BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 285, name: mutex preemptcount: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dumpbacktrace+0x1c/0x24 showstack+0x2c/0x38 dumpstacklvl+0x5a/0x72 dumpstack+0x14/0x1c mightresched+0x130/0x13a rtspinlock+0x2a/0x5c die+0x24/0x112 dotrapinsnillegal+0xa0/0xea newvmallocrestorecontexta0+0xcc/0xd8 Oops - illegal instruction [#1]
Switch to use rawspinlockt, which does not sleep even with PREEMPTRT enabled.
In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: don't keep queue frozen during system suspend
Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending.
block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bioqueueenter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblkfreeze().
[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/
Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.
btrfs: avoid NULL pointer dereference if no valid extent tree
In the Linux kernel, the following vulnerability has been resolved:
net/sctp: Prevent autoclose integer overflow in sctpassociationinit()
While by default maxautoclose equals to INTMAX / HZ, one may set net.sctp.maxautoclose to UINTMAX. There is code in sctpassociationinit() that can consequently trigger overflow.
drm/amd/display: Add check for granularity in dml ceil/floor helpers
In the Linux kernel, the following vulnerability has been resolved:
net: fix memory leak in tcpconnrequest()
If inetcskreqskqueuehashadd() return false, tcpconnrequest() will return without free the dst memory, which allocated in afops->routereq.
Here is the kmemleak stack:
unreferenced object 0xffff8881198631c0 (size 240): comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s) hex dump (first 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [<ffffffffb93e8d4c>] kmemcachealloc+0x60c/0xa80 [<ffffffffba11b4c5>] dstalloc+0x55/0x250 [<ffffffffba227bf6>] rtdstalloc+0x46/0x1d0 [<ffffffffba23050a>] mkrouteoutput+0x29a/0xa50 [<ffffffffba23456b>] iprouteoutputkeyhash+0x10b/0x240 [<ffffffffba2346bd>] iprouteoutputflow+0x1d/0x90 [<ffffffffba254855>] inetcskroutereq+0x2c5/0x500 [<ffffffffba26b331>] tcpconnrequest+0x691/0x12c0 [<ffffffffba27bd08>] tcprcvstateprocess+0x3c8/0x11b0 [<ffffffffba2965c6>] tcpv4dorcv+0x156/0x3b0 [<ffffffffba299c98>] tcpv4rcv+0x1cf8/0x1d80 [<ffffffffba239656>] ipprotocoldeliverrcu+0xf6/0x360 [<ffffffffba2399a6>] iplocaldeliverfinish+0xe6/0x1e0 [<ffffffffba239b8e>] iplocaldeliver+0xee/0x360 [<ffffffffba239ead>] iprcv+0xad/0x2f0 [<ffffffffba110943>] netifreceiveskbonecore+0x123/0x140
Call dstrelease() to free the dst memory when inetcskreqskqueuehashadd() return false in tcpconnrequest().
gpio: xilinx: Convert gpiolock to raw spinlock